NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/6939

Internet Message Format | 1996-08-05 | 3.4 KB

Path: watnews.watson.ibm.com!ncohen
From: [e-mail] (Norman H. Cohen)
Newsgroups: comp.lang.ada,comp.lang.c++
Subject: Re: on OO differnces between Ada95 and C++
Date: 20 Feb 1996 22:36:35 GMT
Organization: IBM T.J. Watson Research Center
Distribution: world
Message-ID: <4gdidj$[e-mail]>
References: <4gbq7q$[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: rios8.watson.ibm.com

In article <4gbq7q$[e-mail]>, [e-mail] (Nasser Abbasi)
observes that in C and C++ one specifies an interface in a .h (or .H)
file and imports the interface with a #include directive, while in Ada
one specifies an interface with a program-unit declaration (typically a
package declaration) and imports it with a with clause.  In C and C++
importing is transitive--if B #includes A and C #includes B, then C has
effectively #included--while in Ada it is not--if B has a with clause for
A and C has a with clause for B, then A is not visible in C unless C has
its own explicit with clause for A.

I prefer the Ada model for two reasons:

1.  The Ada model provides a more precise description of which library
    units are visible where.  A library unit is visible only in
    compilation units naming it in a with clause.  Some Ada programmers
    use subunits to make this information even more precise.  For
    example, if the only place in a large package body where Ada.Text_IO
    is used is in one particular procedure body, that procedure body may
    be broken off into a subunit and the with clause for Ada.Text_IO
    placed on the subunit rather than the package body, to make clear to
    readers that Ada.Text_IO is only used in that one procedure.

2.  In a compilation unit U that refers to an imported entity X, the Ada
    model makes it easier to find the unit exporting X.  It must be a
    unit named in a with clause on U, on the corresponding declaration if
    U is a body, or a parent unit.

When the programmers deem it appropriate, it is possible for one package
to reexport entities declared in another package using renaming, subtype,
and number declarations:

   package A is
      type T is ...;
      procedure P(X: in out T);
      Y: constant T := ...;
      ...
   end A;

   with A;
   package B is
      subtype T is A.T;
      procedure P(X: in out T) renames A.P;
      Y: constant T := A.C;
      ...
   end B;

However, reexport is not forced on the programmer as in the case of a .h
file that #includes another .h file.  In the example above, if a
compilation unit C has a with clause for B and refers to T, P, or Y, the
reader for C can refer to the declaration of B to find declarations for
T, P, and Y.

In OOP, it is often desirable for entities declared along with a parent
type P to be reexported along with any type D derived from P.  This can
be achieved automatically by deriving from P in a child of the package in
which D is declared:

   package Parent is
      type Auxiliary_Type is ...;
      type P is tagged ...;
      procedure Op (X: in out P; Y: in Auxiliary_Type);
      ...
   end Parent;

   package Parent.Child is
      type D is new P with ...;
      procedure Op (X: in out D; Y: in Auxiliary_Type);
      ...
   end Parent.Child;

A compilation unit that mentions Parent.Child in a with clause is, in
effect, really importing a version of Parent with Parent.Child nested
inside of it, so the declaration of Auxiliary_Type comes along.

--
Norman H. Cohen    [e-mail]